Connected user communication and interface system with shuttle tracking application

ABSTRACT

A system and connected user mobile device interface for tracking one or more shuttle buses and providing a visual display thereof along with estimated times of arrival at the connected user&#39;s location or at the shuttle bus stop closest to the connected user. The tracking system is a learning-based model that tracks vehicle movement to estimate arrival time at pre-determined geo-fence locations based on historical behavior for similar time periods and conditions.

This application is a continuation of U.S. patent application Ser. No.16/178,442, filed Nov. 1, 2018, which claims benefit of and priority toU.S. Provisional Application No. 62/580,006, filed Nov. 1, 2017, both ofwhich are incorporated herein by specific reference for all purposes.

FIELD OF INVENTION

This invention relates to a system and related methods for management ofcommunications and interfacing between a user and a connected fleet ofvehicles.

SUMMARY OF INVENTION

In various embodiments, the present invention comprises a system andconnected user mobile device interface for tracking one or more shuttlevehicles (e.g., shuttle buses) and providing a visual display thereof,along with estimated times of arrival at the connected user's locationor at the shuttle vehicle stop closest to the connected user. Thetracking system is a learning-based model that tracks vehicle movementto estimate arrival time at pre-determined geo-fenced locations based onhistorical behavior for similar time periods and conditions. The shuttlevehicles may comprise shuttle buses at an airport, rental vehicleservice shuttle buses at an airport, shuttle buses to transport anypassengers to and from a location (e.g., museum, theater, party, or thelike), commercial or public transportation buses, or similar vehicles.

In one embodiment, the present invention comprises a system for trackingshuttle vehicles, comprising a plurality of shuttle vehicles, eachshuttle vehicle configured with a telematics control unit or a GPSdevice operable to determine shuttle vehicle location along a plannedroute, and an in-vehicle computing device with a device microprocessor;at least one computer server with a server microprocessor programmed to:store a route map encompassing the planned route, wherein the route mapcomprises one or more geo-fence area polygons corresponding to shuttlevehicle stop sites, and one or more geo-fence area polygonscorresponding to shuttle vehicle route sites separate from the shuttlevehicle stop sites; and store historical travel time data for shuttlevehicles traveling along the route map; wherein the devicemicroprocessor in each shuttle vehicle is programmed to determine whenthat shuttle vehicle enters or leaves a shuttle vehicle stop site orshuttle vehicle route site, and transmit a report the entering orleaving, and the time thereof, via wireless electronic communications tothe at least one computer server; and further where the servermicroprocessor is programmed to calculate an expected time of arrival oruntil arrival for a shuttle vehicle to arrive at a particular shuttlevehicle stop site. The device microprocessor determines when thatparticular shuttle vehicle enters or leaves a shuttle vehicle stop siteor shuttle vehicle route site by comparing the shuttle vehicle's GPSlocation as determined by the vehicle's telematics control unit or a GPSdevice with location data for said geo-fence area polygons along theroute. The system may also include a user or customer mobile computingdevice with a microprocessor programmed to receive, via wirelesselectronic communications in real-time, shuttle vehicle locationinformation from the server microprocessor; receive, via wirelesselectronic communications in real-time, estimated arrival time or timesfor one or more shuttle vehicles at one or more locations along theplanned route; and present, on a visual display in real-time, a mapshowing one or more of the following: location of the mobile computingdevice; location of one or more shuttle vehicles; and one or morelocations along the planned route, wherein the one or one or morelocations along the planned route comprise one or more shuttle vehiclestop sites. Further, the visual display may comprise one or moreestimates of time for a shuttle vehicle to arrive at a particularshuttle vehicle stop site, wherein the calculation of expected time ofarrival or until arrival is performed based upon the particular shuttlevehicle's last report with regard to entering or leaving a shuttlevehicle stop site or shuttle vehicle route site, the route-basedrelationship of such reported shuttle vehicle stop site or shuttlevehicle route site to the particular shuttle vehicle stop site, and aselected subset of said historical travel time data. The calculation ofexpected time of arrival or until arrival is not based on generaltraffic usage, patterns, or conditions for the area in which the plannedroute is located. The selected subset of said historical travel data maycomprise data for a particular time of day, for a particular day of theweek, for a particular date, or for a historical time data window. Thewindow may extend back continuously for a set period of time from thetime of calculation, or may be limited to a selected period of time fromthe prior year. The shuttle vehicle route sites may include deviationsites not overlaying the planned route, and are placed to indicateshuttle vehicle deviations from the planned route.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the system architecture of a mobile device used tocommunicate with a vehicle and reservation server of a connected fleet.

FIG. 2 shows an example of a mobile device interface display.

FIG. 3 shows an example of a shuttle tracking map view.

FIGS. 4-8 shows examples of alternative shuttle tracking map views.

FIG. 9 shows an example of shuttle vehicle route creation interface.

FIG. 10 shows an example of a Default Route map.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In various exemplary embodiments, the present invention comprises asystem and related methods for management of communications andinteractions between a user and a connected fleet of vehicles. A“connected fleet” comprises a plurality of vehicles, some or allequipped with (i) on-board sensors and computer systems for monitoringand capturing the operational status and performance of vehicle systemsand components, and (ii) one or more electronic control and/orcommunications units for two-way or multiple pathway communication withone or more fleet management servers or networks, outside data centersor sources, other vehicles, and individual user or driver computingdevices. A “connected user” comprises a user with one or more computingdevices, including, but not limited to, mobile computing devices such assmart phones, tablets, or wearable devices, that provide extended,continuous, uninterrupted electronic communications with variouscomputer networks, devices, and systems, including, but not limited to,elements of the connected fleet computing system or network, regardlessof where the user is and how they are connected. Connected users mayinclude, but are not limited to, drivers, passengers, customers,renters, members of a vehicle sharing service, employees, owners, oroperators.

Vehicles in a connected fleet may include, but are not limited to,automobiles, trucks, vans, buses, motorcycles, bicycles, mopeds,construction and utility vehicles, battery-powered carts, golf carts,airplanes, aircraft, boats, watercraft, and the like. Vehicles may becontrolled by a driver or user, or autonomous or semi-autonomous. Afleet may include, but is not limited to, a rental vehicle fleet, sharedvehicle fleet, peer-to-peer or business-to-business transportationfleet, taxi-cab fleet, corporate vehicle fleet, municipal orgovernmental agency vehicle fleet, bus fleet, utility or constructionvehicle fleet, truck fleet, or combinations thereof. A fleet may behomogenous or heterogeneous (i.e., a mixed fleet). Fleets may becombined to make larger fleets, and fleets may also be sub-divided intocomponent fleets by various parameters (e.g., type of use, type ofcustomer or user, country, state, city, county, or other definedgeographical area). The term “fleet” as used herein includes fleets ofall types and various combinations, components or sub-divisions thereof.

As described in detail below, in several embodiments the presentinvention comprises a unique, single integrated platform forcommunications between a connected user and a connected fleet managementsystem. The connected fleet management system manages fleet planning,in-fleeting operations, vehicle acquisition and provisioning, vehicleassignment, vehicle transfers (i.e., to another fleet or anothercomponent fleet in the larger fleet), vehicle use operations (i.e.,reservations, use and return by a customer, member, driver or user),vehicle servicing, vehicle maintenance and repairs, and de-fleetingoperations (e.g., removal of the vehicle from the fleet, return tomanufacturer, or sale to third parties).

Within this context, the system provides a variety of user-facingapplications and interfaces, including applications which may beinstalled and run on a mobile computing device of the user for variousfunctions. These functions include, but are not limited to, userregistration or enrollment, user reservation management, user access toa fleet vehicle, communication between the user and the fleet managementsystem during use (including, but not limited to, providing roadside oremergency assistance), and return of the fleet vehicle.

In several exemplary embodiments, the present invention comprises one ormore systems or applications for enrolling or registering users. Typesof users vary depending on the nature of the fleet. For example, usersmay be employees of the owner of a corporate or municipal utility fleet,authorized drivers of a bus fleet, drivers of taxi-cabs, renters orcustomers of a car rental agency, or members of a car sharing service.Accordingly, the types of user registration or enrollment system willvary as well. In general, the user enrollment or registration componentcollects necessary information from the users, and reviews potentialusers backgrounds and qualifications, including, but not limited to,user training, licensure reviews, background checks, and credit checks,as appropriate. In some business models, enrollment may comprise anapplication and acceptance as a member of a car sharing or similarservice. Advertising or other means of solicitation of potential usersmay be included. In some cases, users may not be previously enrolledprior to an initial reservation or use, and some or all of these checksmay be performed at the time the user reserves a vehicle or initiallytakes possession of a vehicle.

Users of a particular fleet may be divided into different categories orclassifications (e.g., a preferred or frequent driver program for a carrental company, or users licensed for certain types of vehicles). Inseveral embodiments, the system may comprise a “trusted user” program,where the user has meet certain pre-qualifications and undergonesubstantive background and credit checks. A “trusted user” may receivecertain advantage and perquisites, such as access to special vehicles,quicker and easier access to vehicles, and quicker and easier returns.

In several embodiments, the present invention further comprises one ormore reservation systems or applications. These comprise bothuser-facing and internal fleet system elements. An example of amulti-tiered fleet management reservations database caching system isdescribed in U.S. Pat. No. 9,576,254 (issued Feb. 21, 2017 to Zipcar,Inc.), which is incorporated herein by specific reference for allpurposes. Examples of a reservations interface for a user to identifyavailable vehicles and make a reservation are provided in U.S. Pub. No.2013/0226633 (published Aug. 29, 2013 by Zipcar, Inc.) and U.S. Pub. No.2011/0060480 (published Mar. 10, 2011 by Zipcar, Inc.), which areincorporated herein by specific reference for all purposes. In oneexemplary embodiment, for example, as seen in FIG. 1, a mobile device100 runs a mobile device application for reserving and accessing areservable asset, such as a vehicle 104. The mobile device applicationcan be installed on the mobile device or it can be accessed through aweb application. The mobile device electronically communications with areservation server 101 that is part of a connected fleet managementsystem. The reservation server is in communication with a reservationdatabase 102. The reservation server provides information aboutreservable vehicles to the mobile device, including reservable assets(typically for a requested time period and location of interest). Themobile device application may display a map of locations of reservablevehicles, enabling users to search and view locations as desired. Themobile device application also may display reservable vehicles in listformat. Users may mark certain vehicle types, or specific vehicles, as a“favorite” for facilitating future searches.

The present invention further comprises a vehicle access component, thatalso may comprise both user-facing and internal fleet system elements.This may be part of the reservations system or work in conjunction witha reservations system. The user seeks access in a variety of ways,including, but not limited to, obtaining keys to the vehicle from a carrental agent, presenting an authorized user card to a card reader in thevehicle, or using a mobile computing device to communicate with a TCU ordedicated access unit in the vehicle, as discussed above. Examples ofaccess control systems are disclosed in U.S. Pat. No. 9,442,888 (issuedSep. 13, 2016) and U.S. Pat. No. 9,635,518 (issued Apr. 25, 2017), whichare incorporated herein by specific reference for all purposes.

In cases where the user is attempting key-less access to a connectedvehicle, such as by wireless communication with a user's mobilecomputing device, there are several methods to determine whether toallow access. In some cases, access may be permitted if the user is apre-authorized registered user, and presents a general access code orauthorization to the vehicle. In other cases, reservation data (eitherfor a single reservation or for reservations over a period of time,which can be a day or several days) has been previously electronicallycommunicated to the vehicle (e.g., transmitted to a TCU in the vehicle)and stored therein, and access is permitted if a user attempting accessmatches corresponding reservation data (i.e., user identity, timeperiod, and the like). Alternatively, after receiving an access requestfrom a user, the vehicle (i.e., through TCU or similar unit)electronically communicates with the fleet management system to confirmwhether or not to allow access. In cases where the vehicle cannotestablish direct communication access, it may attempt to establishcommunication through other connected vehicles, through the user'smobile device, or other wireless access points.

In some cases, such as an underground garage or parking area, thevehicle and user's computing device may be unable to establish outsidecommunications links in any fashion. In several embodiments, the fleetmanagement system of the present invention previously provides aprotected, secure, single-use token to the user's computing device uponmaking a reservation (or close to the starting time of the reservation),which is then securely communicated to the vehicle by the user'scomputing device through local wireless communications means (e.g., BLE,NFC, and the like). The vehicle processes the token, and allows accessif the information in the token is valid.

After access is allowed, the period of use commences. During use, asdescribed above, the connected vehicle (or a TCU or a similar unit inthe vehicle) provides various information to the fleet managementsystem. The fleet management system may directly or indirectly monitorsome or all of the period of use. In several embodiments, the fleetmanagement system monitors the period of use for emergency situations,which may be reported by the user through an application on the user'smobile device or a unit in the vehicle. The user can establishconnection directly with the fleet management system or an road-sideassistance or emergency response team or service, and requestassistance.

In several embodiments, the user may communicate an incident or accidentin real-time or near real-time during the use period. Information may begathered in real time by the user using the application on their mobilecomputing device, including descriptions and pictures of any damage tothe vehicle. This information can then be provided to the fleetmanagement system's servicing or maintenance components for advanceplanning and scheduling prior to return of the vehicle.

The user may be contacted if the fleet management system detects thatthe vehicle may be returned late, or at a different location thanidentified in the reservation, as described in U.S. Pub. No.2013/0246102 (published Sep. 19, 2013 by Zipcar, Inc.) which isincorporated herein by specific reference for all purposes. The fleetmanagement system can assist the user in extending or modifying thereservation if necessary, and may contact other users that may beaffected by the late return.

The present invention further comprises vehicle return applications orcomponents, which handle, among other things, determination of thevehicle status and condition, invoicing of the user (where appropriate),and forwarding of the vehicle for any servicing, maintenance, or repairsthat may be required. These also may comprise user-facing and internalfleet elements. For example, a user may return a vehicle to a planneddrop-off location, then automatically check-in through an application ontheir mobile computing device. The user may be prompted to confirmmileage and gas levels (which the connected vehicle may communicatedirectly to the fleet management system), and electronically sign thefinal invoice. An electronic receipt may be sent to the user through theapplication, email, or other form of electronic communication. If thevehicle is damaged, the application may be used to record/photograph thedamage, and the system may then automatically, in real time, calculate adamage charge to add to the user invoice at the time of return. Themobile device may be used to capture the electronic signature of thecustomer or user returning the vehicle, including the damage charge.

Shuttle Bus Tracking System

In several embodiments, the present invention comprises a system andconnected user mobile device interface for tracking one or more shuttlevehicles (e.g., shuttle buses) and providing a visual display thereof(see FIGS. 2-8), along with estimated times of arrival at the connecteduser's location or at the shuttle vehicle stop closest to the connecteduser. The tracking system is a learning-based model that tracks vehiclemovement to estimate arrival time at pre-determined geo-fenced locationsbased on historical behavior for similar time periods and conditions.

Estimating shuttle bus arrival time at a particular location isdifficult for several reasons. First, it is variable based oncustomer/rider volume and usage: a shuttle vehicle arriving at stop Awill spend a longer period of time at stop A if there are asignificantly large number of riders who need to unload at stop A,and/or who need to load at stop A. The amount of time the shuttlevehicle stays at stop A will impact its arrival time at the next stop(stop B). Second, shuttle vehicle drivers coordinate in real time, andthus a particular shuttle vehicle may skip a stop where it has no ridersto drop and a preceding shuttle vehicle remains, or may “double up” on astop with another vehicle, depending on customer usage. Finally, generaltraffic pattern data alone is not accurate to estimate arrival time, asshuttle vehicles often use dedicated lanes or areas that are not subjectto typical local traffic usage or patterns. Accordingly, prior artsystems that estimate travel or arrival time based on location, assumedtravel speed, and/or local traffic usage or patterns, will not providesufficiently accurate estimates of arrival time in this context.

The shuttle vehicle tracking system of the present invention overcomesthe above difficulties by collecting real-time GPS location coordinatedata (from a TCU or GPS device or system in the shuttle vehicle) as eachshuttle vehicle travels the shuttle route (e.g., from the rental vehiclestation or area to various stops at an airport or similar facility), andrecording and storing the location and corresponding time (and in somecases, day or date) data. The shuttle route pattern thus is dynamicallylearned over time for one or a plurality of shuttle vehicles travelingthe route. Using “snap-to” algorithms as described below, the locationcoordinate data is mapped to adjacent roads that the vehicle istraveling, which can be displayed on a map with bus route locations.Thus, there is no initial route mapping and storage: the routes aredynamically learned and tracked based on real-time shuttle vehicletravel. Shuttle travel and location information also may be collectedvia a low earth orbit microsatellite system, such as that disclosed inU.S. patent application Ser. No. 15/986,504, filed May 22, 2018 and Ser.No. 15/986,375, filed May 22, 2018, both of which are incorporatedherein by specific reference for all purposes.

This historical data is used to estimate the travel time between pointson the route, and between a current shuttle vehicle location and a pointon the route, for different periods of the day. The historical datawindow may cover several days, weeks, or months. The historical datawindow may extend backward continuously, or be limited to a selectedperiod of time (e.g., the same holiday period from last year).Variations between the current data being recorded and the historicaldata can be observed and used to modify the estimated current travel andarrival times. In several embodiments, the system does not use actualgeneral traffic patterns or conditions for determining travel andarrival times.

In several embodiments, users may download an application program on theuser computing device (e.g., smart phone, cellphone, tablet computingdevice, mobile computing device, laptop computer, or the like). Theapplication program allows the user (e.g., customer) to track shuttlevehicles, such as the nearest shuttle vehicle and/or the shuttle vehiclenext to arrive at a particular location.

FIG. 2 is an example of a visual display 200 showing a track shuttleoption 202 from a mobile application on a smart phone. The applicationthen displays a map view 204 (which the user can zoom in or out, orreposition to cover a different geographic area) with estimated times206 for the next shuttle (and following shuttle) to arrive at the user'spick-up/drop-off location (or the pick-up/drop-off location closest tothe user's actual location), and estimated times 208 for the nextshuttle (and following shuttle) to arrive at the lot or parking areawhere rental vehicles are located. Note that this lot location can beanother location of particular interest, such as a bus depot, or otherlocation of interest at which shuttle vehicles are dropping and pick-uppassengers. In some embodiments, no special lot location or similarlocation of particular interest may be indicated. In some embodiments,multiple locations of special interest may be specially indicated ormarked.

On the map view in FIG. 3 (which shows roads, buildings, and otherstructures or features in the area), the application also shows theuser's location 210 (determined, for example, by GPS systems embedded inthe user's computing or mobile device), the closest or user-chosenpick-up location (indicated as “A” here) 220, the lot location orsimilar location of particular interest 230, and the approximatelocation 240 of some or all shuttle vehicles on the route. As discussedbelow, the location of a shuttle vehicle may be determined based upon areport from the vehicle as it enters or exits designated geo-fences (or“sites”) on the route. When a shuttle vehicle reports this informationto the system server (or servers), the system updates its calculation ofestimated arrival time(s) based on historical data and other factors asdescribed above.

Other icons or graphic indicators may be used. For example, FIG. 4 showsan example of a colored icon indicate the closest pick-up location 220,with two shuttle vehicles shown. FIG. 5 shows a close-up view, with thenext shuttle vehicle highlighted 242. FIG. 6 shows a more remote view,with multiple “following” shuttle vehicles indicated. FIG. 7 showsanother close-up view, also indicating a rental agency location or boothat the airport 250. FIG. 8 shows another close-up view, with severalpick-up drop-off locations 224 and several shuttle vehicles indicated.In some embodiments, the user can select a particular vehicle or stopicon to obtain more information, such the stop or vehicle name oridentification information.

The user interface can be modified in scale and scope, and show thelocation of the customer/user, the real-time location of the closestshuttle vehicle/bus to the customer/user, the real-time location ofmultiple shuttles/buses on the map, the location of various route stops,and the location of the rental vehicle lot. The interface also will showthe estimated time of arrival for the next shuttle vehicle/bus at thecustomer/user location, or at the shuttle stop nearest the customer/user(in the latter case, the interface also may provide an estimated traveltime for the customer/user to reach the shuttle stop). The estimatedtimes of arrival for sequential shuttle vehicles/buses also may bedisplayed.

The system also may be used by a customer/user on a shuttle vehicle fordetermining the estimated time of arrival at the next stop or at aselected stop along the route. Further, while the system has beendescribed above in the context of a rental vehicle shuttle bus, it mayalso be used for tracking other vehicles, especially vehicles travelingalong a pre-determined route, such as buses, trolleys, or the like.

FIG. 9 shows an interface screen 300 for an administrative user tocreate or modify a shuttle vehicle route for tracking. A series ofgeo-fence polygons (referred to herein as “sites”) are created andsuperimposed on the roads or other areas that the shuttle vehicles willtravel. In this embodiment, there are two types of sites: “Vehicle Stop”(or “Bus Stop”) sites 310 and “Vehicle Route” (or “Bus Route”) sites320.

Vehicle Stop sites show all pick-up and drop-off stops on the route,including the rental location or lot, and may be identified by name,description, and/or unique ID number. The location and site descriptionmay use to provide more details about the stop or route location, andmay be named in accordance with naming conventions adopted for thesystem. In general, as each shuttle vehicle travels along the route, asystem application with route data that has been downloaded to and isoperable on a computing device in the shuttle vehicle, records when ithas entered one of the defined sites (based on GPS coordinates of thevehicle), and reports it in real time through, e.g., wireless orcellular communications, to the main system server. It may also recordand report when it exits one of the defined sites. The main systemserver then performs estimated arrival time calculations to be sent tocustomer/user applications (as described above).

Vehicle Route sites show defined points or areas on the vehicle route orroutes that are used to provide additional information between VehicleStop sites. These sites may be named and identified is a similar mannerto Vehicle Stop sites. Any number of Vehicle Route sites may be added,and typically are added if there is a long span between Vehicle Stopsites and the intermediate route site is used to obtain shuttle vehiclelocation and time data to provide more accurate estimates of arrivaltimes. Vehicle Route sites also may be used if there are points (i.e.,Exception Sites) where the route may diverge from the standard or baseroute (e.g., where the vehicle may take one of two or more paths, or maydeviate from the base route to either skip a stop where it has nopassengers to drop-off, is too full to take more riders, or otherreason).

The system may track multiple shuttle vehicle fleets (such as brands orsub-brands), where each brand or sub-brand has separate vehicles, androutes may vary. In some embodiments, shuttle vehicles are shared, andtreated as a single fleet. Each shuttle vehicle is assigned to a fleet,and has a unique name or ID, which may be numeric or alpha-numeric. Insome embodiments, these vehicle name or ID with identification signageon the vehicle (e.g., on the front of the bus visible to customers), sothat users of the mobile device application can match a vehicle with anicon on the application.

In several embodiments, as seen in FIG. 10, the system creates a“Default Route” (or standard or base route), which is the ordered listof stops that each shuttle vehicle will take in traversing the routefrom beginning to end, assuming no exceptions (i.e., no divergences).The timing of a Default Route for a particular date and/or time assumesthat all stops are made in order from beginning to end. All estimatedtimes between stops (and/or sites) are calculated assuming the bus willtravel the default route between sites, and using historical travel data(as described above). A shuttle vehicle may change its path whilenavigating the route for a number of reasons (as described above withregard to Exceptions). If a shuttle vehicle deviates from the DefaultRoute, future arrival times are based on the off-route location of thevehicle as determined by the real-time vehicle location, or if thedeviation keeps the vehicle on a known or alternate route mapped in thesystem, by using historical data in conjunction with new site entry/exitdata reported by the vehicle.

FIG. 10 shows an example of a Default Route (the dark (blue) line withtravel direction arrows) map with stop and route sites for an airport.The stop and route sites are indicated alphabetically in order oftravel, starting with A and ending with I. Pick-up sites (with orwithout drop-off as well) are indicated with a “+” (drop-off only sitesare not specially indicated; e.g., A+ is the pick-up site for the rentalservice lot, while I is the drop-off only site at the same rentalservice lot). Some sites are multi-pass sites, e.g., the vehicle passesthrough the main terminal twice, once for drop-off only (D), and oncefor pick-up (F+). The light (yellow) lines show common deviations (i.e.,Exceptions) from the Default Route. Exception sites are labeled outsidethe alphabetical travel order of the Default Route, and are denoted witha “−” (e.g., “J−” indicates an Exception Site).

Computer Implementation

In order to provide a context for the various computer-implementedaspects of the invention, the following discussion provides a brief,general description of a suitable computing environment in which thevarious aspects of the present invention may be implemented. A computingsystem environment is one example of a suitable computing environment,but is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. A computing environment may contain anyone or combination of components discussed below, and may containadditional components, or some of the illustrated components may beabsent. Various embodiments of the invention are operational withnumerous general purpose or special purpose computing systems,environments or configurations. Examples of computing systems,environments, or configurations that may be suitable for use withvarious embodiments of the invention include, but are not limited to,personal computers, laptop computers, computer servers, computernotebooks, hand-held devices, microprocessor-based systems,multiprocessor systems, TV set-top boxes and devices, programmableconsumer electronics, cell phones, personal digital assistants (PDAs),tablets, smart phones, touch screen devices, smart TV, internet enabledappliances, internet enabled security systems, internet enabled gamingsystems, internet enabled watches; internet enabled cars (ortransportation), network PCs, minicomputers, mainframe computers,embedded systems, virtual systems, distributed computing environments,streaming environments, volatile environments, and the like.

Embodiments of the invention may be implemented in the form ofcomputer-executable instructions, such as program code or programmodules, being executed by a computer, virtual computer, or computingdevice. Program code or modules may include programs, objects,components, data elements and structures, routines, subroutines,functions, and the like. These are used to perform or implementparticular tasks or functions. Embodiments of the invention also may beimplemented in distributed computing environments. In such environments,tasks are performed by remote processing devices linked via acommunications network or other data transmission medium, and data andprogram code or modules may be located in both local and remote computerstorage media including memory storage devices such as, but not limitedto, hard drives, solid state drives (SSD), flash drives, USB drives,optical drives, and internet-based storage (e.g., “cloud” storage).

In one embodiment, a computer system comprises multiple client devicesin communication with one or more server devices through or over anetwork, although in some cases no server device is used. In variousembodiments, the network may comprise the Internet, an intranet, WideArea Network (WAN), or Local Area Network (LAN). It should be noted thatmany of the methods of the present invention are operable within asingle computing device.

A client device may be any type of processor-based platform that isconnected to a network and that interacts with one or more applicationprograms. The client devices each comprise a computer-readable medium inthe form of volatile and/or nonvolatile memory such as read only memory(ROM) and random access memory (RAM) in communication with a processor.The processor executes computer-executable program instructions storedin memory. Examples of such processors include, but are not limited to,microprocessors, ASICs, and the like.

Client devices may further comprise computer-readable media incommunication with the processor, said media storing program code,modules and instructions that, when executed by the processor, cause theprocessor to execute the program and perform the steps described herein.Computer readable media can be any available media that can be accessedby computer or computing device and includes both volatile andnonvolatile media, and removable and non-removable media.Computer-readable media may further comprise computer storage media andcommunication media. Computer storage media comprises media for storageof information, such as computer readable instructions, data, datastructures, or program code or modules. Examples of computer-readablemedia include, but are not limited to, any electronic, optical,magnetic, or other storage or transmission device, a floppy disk, harddisk drive, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, EEPROM,flash memory or other memory technology, an ASIC, a configuredprocessor, CDROM, DVD or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium from which a computer processor can readinstructions or that can store desired information. Communication mediacomprises media that may transmit or carry instructions to a computer,including, but not limited to, a router, private or public network,wired network, direct wired connection, wireless network, other wirelessmedia (such as acoustic, RF, infrared, or the like), or othertransmission device or channel This may include computer readableinstructions, data structures, program modules or other data in amodulated data signal such as a carrier wave or other transportmechanism. Said transmission may be wired, wireless, or both.Combinations of any of the above should also be included within thescope of computer readable media. The instructions may comprise codefrom any computer-programming language, including, for example, C, C++,C#, Visual Basic, Java, and the like.

Components of a general purpose client or computing device may furtherinclude a system bus that connects various system components, includingthe memory and processor. A system bus may be any of several types ofbus structures, including, but not limited to, a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. Such architectures include, but are not limited to,Industry Standard Architecture (ISA) bus, Micro Channel Architecture(MCA) bus, Enhanced ISA (EISA) bus, Video Electronics StandardsAssociation (VESA) local bus, and Peripheral Component Interconnect(PCI) bus.

Computing and client devices also may include a basic input/outputsystem (BIOS), which contains the basic routines that help to transferinformation between elements within a computer, such as during start-up.BIOS typically is stored in ROM. In contrast, RAM typically containsdata or program code or modules that are accessible to or presentlybeing operated on by processor, such as, but not limited to, theoperating system, application program, and data.

Client devices also may comprise a variety of other internal or externalcomponents, such as a monitor or display, a keyboard, a mouse, atrackball, a pointing device, touch pad, microphone, joystick, satellitedish, scanner, a disk drive, a CD-ROM or DVD drive, or other input oroutput devices. These and other devices are typically connected to theprocessor through a user input interface coupled to the system bus, butmay be connected by other interface and bus structures, such as aparallel port, serial port, game port or a universal serial bus (USB). Amonitor or other type of display device is typically connected to thesystem bus via a video interface. In addition to the monitor, clientdevices may also include other peripheral output devices such asspeakers and printer, which may be connected through an outputperipheral interface. Client devices may operate on any operating systemcapable of supporting an application of the type disclosed herein.Client devices also may support a browser or browser-enabledapplication. Examples of client devices include, but are not limited to,personal computers, laptop computers, personal digital assistants,computer notebooks, hand-held devices, cellular phones, mobile phones,smart phones, pagers, digital tablets, Internet appliances, and otherprocessor-based devices. Users may communicate with each other, and withother systems, networks, and devices, over the network through therespective client devices.

As used herein, the singular forms “a,” “an” and “the” include pluralreferents unless the context clearly dictates otherwise. Further, theterms “additional”, “optional”, “optionally”, “may” and the like meanthat the subsequently described operation, event or functionality mayormay not be required, and that the description includes instances wheresaid operation, event or functionality occurs and instances where itdoes not. The word “comprise” and variations of that word, and the word“include” and variations of that word, mean “including but not limitedto,” and are not intended to exclude, for example, other components,steps, or operations. “For example” and “exemplary” mean “an example of”and are not intended to convey an ideal embodiment.

Thus, it should be understood that the embodiments and examplesdescribed herein have been chosen and described in order to bestillustrate the principles of the invention and its practicalapplications to thereby enable one of ordinary skill in the art to bestutilize the invention in various embodiments and with variousmodifications as are suited for particular uses contemplated. Thesystem, methods and apparatus of the present invention are not limitedto specific components, network connections, or arrangements describedand disclosed herein, as such may vary. It is also to be understood thatthe terminology used herein is for the purpose of describing particularembodiments only, and is not intended to be limiting. Even thoughspecific embodiments of this invention have been described, they are notto be taken as exhaustive. There are several variations that will beapparent to those skilled in the art.

What is claimed is:
 1. A system for tracking shuttle vehicles,comprising: a plurality of shuttle vehicles, each shuttle vehicleconfigured with an electronic control device operable to determineshuttle vehicle location along a planned route; at least one computerserver with a server microprocessor programmed to: store a route mapencompassing the planned route; store historical travel time data forshuttle vehicles traveling along the route map; receive, via wirelesselectronic communication, a location report from the electronic controldevice in a particular one of said plurality of shuttle vehicles; andcalculate an expected time of arrival or until arrival for a shuttlevehicle to arrive at a particular shuttle vehicle stop site based uponthe particular shuttle's vehicles last location report with regard toentering or leaving a shuttle vehicle stop site or shuttle vehicle routesite, a route-based relationship of such reported shuttle vehicle stopsite or shuttle vehicle route site to the particular shuttle vehiclestop site, and at least some of said historical travel time data.
 2. Thesystem of claim 1, wherein the electronic control device determines whenits associated shuttle vehicle enters or leaves a shuttle vehicle stopsite or shuttle vehicle route site by comparing the shuttle vehicle'sGPS location with location data for said shuttle vehicle stop site orshuttle vehicle route site.
 3. The system of claim 1, further comprisinga mobile computing device with a microprocessor programmed to: receive,via wireless electronic communications in real-time, shuttle vehiclelocation information from the server microprocessor; receive, viawireless electronic communications in real-time, estimated arrival timeor times for one or more shuttle vehicles at one or more locations alongthe planned route; and present, on a visual display in real-time, a mapshowing one or more of the following: location of the mobile computingdevice; location of one or more shuttle vehicles; and one or morelocations along the planned route.
 4. The system of claim 3, wherein theone or one or more locations along the planned route comprise one ormore shuttle vehicle stop sites.
 5. The system of claim 4, furtherwherein the visual display further comprises one or more estimates oftime for a shuttle vehicle to arrive at a particular shuttle vehiclestop site.
 6. The system of claim 5, wherein the calculation of expectedtime of arrival or until arrival is not based on general traffic usage,patterns, or conditions for the area in which the planned route islocated.
 7. The system of claim 1, wherein the at least some of saidhistorical travel data is for a particular time of day.
 8. The system ofclaim 1, wherein the at least some of said historical travel data is fora particular date or day of the week.
 9. The system of claim 1, whereinthe at least some of said historical travel data is from a historicaldata window.
 10. The system of claim 9, wherein the historical datawindow extends back continuously for a set period of time from the timeof calculation.
 11. The system of claim 9, wherein the historical datawindow is limited to a selected period of time from the prior year. 12.The system of claim 1, wherein the plurality of shuttle vehiclescomprise shuttle buses at an airport.
 13. The system of claim 1, whereinthe plurality of shuttle vehicles comprise passenger buses.
 14. Thesystem of claim 1, wherein the shuttle vehicle route sites includedeviation sites not overlaying the planned route, and are placed toindicate shuttle vehicle deviations from the planned route.